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Abstract — NASA's future communications services will 
be supplied through a space communications network that 
mirrors the terrestrial Internet in its capabilities and flexi- 
bility. The notional requirements for future data gathering 
and distribution by this Space Internet have been gathered 
from NASA’s Earth Science Enterprise (ESE), the Human 
Exploration and Development in Space (HEDS), and the 
Space Science Enterprise (SSE). 

This paper describes a communications infrastructure for 
the Space Internet, the architectures within the infrastruc- 
ture, and the elements that make up the architectures. The 
architectures meet the requirements of the enterprises 
beyond 2010 with Internet compatible technologies and 
functionality. The elements of an architecture include the 
backbone, access, inter-spacecraft, and proximity commu- 
nication parts. From the architectures, technologies have 
been identified which have the most impact and are critical 
for the implementation of the architectures. 
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1. Introduction 

By analysis of missions in the conceptual phase and dis- 
cussion with the NASA enterprises, the requirements 
beyond 2010 include high data rates, high capacity, inter- 
activity with the in-space instrument, security of opera- 
tions, real time data delivery, and seamless interoperability 
between in-space entities. The architecture that can be 
responsive to the requirement is the Open Standard Inter- 
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connection (OSI) seven-layer model or its derivatives [1]. 
The advantages expected from this combination are signif- 
icant increases in the quantity of data handled and the sim- 
plification of delivering that data to its destination. The 
improvements in data delivery are derived from the pres- 
ent capabilities and the continuous improvement in capa- 
bility that commercial industry brings to the Internet - 
without charge to NASA. 

Vertical Vs Horizontal Infrastructure 

NASA's communications infrastructure has grown out of 
the need to provide special services to each new mission as 
they were implemented. A vertically organized mission 
used infrastructure pieces that were designed to that single 
mission’s requirements - resulting in communications 
assets only useful to that single mission. While it was pos- 
sible to reuse some of the assets, such as the larger ground 
antennas, even these had to be modified to handle new 
mission requirements as they came along. Since this hard- 
ware was designed to operate at the lower frequencies (S- 
and X-band) and was not designed for flexibility, it has 
been increasingly difficult to bring the assets up to the 
capability of the commercial satellite systems that now 
operate at very high bit rates in the K-band. 

NASA must consolidate its communications assets into a 
more horizontal infrastructure [2][3][4] so that the capabil- 
ities can be used to the advantage of any kind of mission 
that may wish to “plug-in” to it. The infrastructure must be 
revised to meet general specifications rather than meet any 
specific mission's requirements [5]. Missions would then 
be designed to interface to a general, highly capable, and 
standardized infrastructure. Once the infrastructure has 
been “flattened” and modified to provide high qualities of 
service to any mission type, further developmental activity 
will concentrate on continuous improvement of the capa- 
bilities of the infrastructure to the benefit of all missions. 

NASA’s technology programs have taken on the early 
development of the hardware needed to make the initial 
changes [6] to the infrastructure and enable it to leapfrog 
beyond the present commercial communications capabili- 
ties. However, NASA is also aware of and will take advan- 
tage of the capabilities offered by the Internet and its tech- 
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Figure 1, Simplified view of NASA’s future communications infrastructure 


nologies. One of the primary advantages of the Internet is 
that it is truly horizontal in its structure. That is, anyone 
can procure a computing device, connect to the Internet, 
and communicate through it because of the great flexibility 
and highly diverse set of open interoperability standards 
that the Internet conforms to and that are provided within 
each computing device. 

This paper discusses the basic architectures identified and 
that are needed to support three of the NASA enterprises: 
the Earth Science Enterprise (ESE), the Human Explora- 
tion and Development in Space (HEDS), and the Space 
Science Enterprise (SSE). These architectures were 
inspected for similar aspects that were broken out as sepa- 
rate architectural elements. 

Figure 1 displays a simple diagram of the extent of the 
infrastructure and the architectural elements, but without 
reference to the actual architectures. The figure shows the 
end-to-end connectivities between the scientists, the mis- 
sion spacecraft, and instruments that NASA is striving for. 
Since this new infrastructure is based on Internet technolo- 
gies, mission operations, hardware and spacecraft vendors, 
and the public (providing they are authorized), are afford- 
ed the same connectivity to NASA's exploration, science, 
and hardware. 

The general infrastructure is discussed below and includes 
the following architectural element: 

♦ Backbone network - the space network (SN), the 
ground network (GN), NASA’s Intranets and virtual 
private networks (VPN's), the Internet, and any com- 
mercial or foreign communications system that 


may be employed: 

♦ Access networks - the radio and/or optical communi- 
cation interfaces between the backbones and the mis- 
sion spacecraft and/or vehicles, and the local area net- 
works (LAN’s) on-board the spacecraft and/or 
vehicles; 

♦ Inter-spacecraft networks - the radio and/or optical 
communication interfaces between spacecraft flying in 
a constellation, formation, or cluster; 

♦ Proximity networks - the radio and/or optical commu- 
nication interfaces between vehicles (rovers, airplanes, 
aerobots), landers, and sensors spread out in an ad hoc 
network. 

2. Architectural Elements 

Backbone Networks 

These networks, indicated in Figure 2, include NASA's 
GN and SN (the Tracking and Data Relay Satellite System 
- TDRSS) and any commercial satellite systems that might 
be employed to provide communications services to 
NASA spacecraft. The backbone network also includes the 
VPN’s that tie NASA's assets together. Information avail- 
able through the backbone network, includes data and 
tasking directives from: other spacecraft, vehicles, sensor 
networks, operations centers, archival databases, and 
users. The networks further enable pathways to foreign 
and domestic resources available on the Internet. Informa- 
tion access can significantly improve a mission’s science 
by enabling coordination of activities and by providing 
data to a spacecraft to facilitate on-board processing. 








Figure 2, Backbone Network Elements 


The data path through a backbone network is shown in 
Figure 3. The protocols levels that are used to handle the 
data that passes through the networks are shown on the 
left. The actual protocols to be used through the various 
network elements are under investigation. The unlabeled 
protocol levels are shown to give a sense of where proto- 
col conversions are likely to occur in the networks. 

Notionally, the user connects to the backbone via NASA’s 
Intranet (by local Ethernet or dial-in connection), or 
through a secured route over the public Internet. The user 
and network switch shown on the left are at a NASA cen- 
ter on the NASA Intranet. The Intranet is connected to a 
ground station via a Virtual Private Network (VPN) allo- 
cated on a Wide Area Network (WAN) provided by a pri- 
vate company. Protocols that may be used on WAN’s 
include Asynchronous Transfer Mode (ATM), Synchro- 
nous Optical NETwork (SONET), and frame relay. The 
ground station’s Local Area Network (LAN) is most likely 
Ethernet or ATM. When the backbone is directly connect- 
ed to a user spacecraft, the data can be directly passed on 
through to the user in real time, assuming the user is online 
or has an online autonomous system for capturing data. If 
the spacecraft is communicating with a NASA backbone 
network but the user is not connected to the backbone 
(e.g., when the WAN connection is down), tasking or 


science/telemetry data (depending on which entity is 
connected) is temporarily stored on a gateway server’s fast 
Redundant Array of Inexpensive Disks (RAID) to be 
passed on later when a connection is established. User 
spacecraft connect to the backbone via modulated radio 
frequency or optical (RF/O) signals. The present interfaces 
are the antennas of the Ground Network (GN - NASA 
sites, foreign sites, and corporate sites), the Tracking and 
Data Relay Satellites (TDRS’s) of NASA’s Space Network 
(SN), and the antennas of the Deep Space Network (DSN). 

Access Networks 

These networks are the RF/O interfaces to the outer edges 
of the backbone networks for mission spacecraft, vehicles, 
and other entities. These interfaces, shown in Figure 4, 
include the remote entity ‘s modem, receiver, transmitter, 
and antenna as well as the backbone^ matching set. Infor- 
mation can also be obtained by direct communication to 
other spacecraft or landed vehicle or stationary entities. 



For instance, an over-flying earth observing spacecraft 
might access data from meteorological buoys and balloons 
and then integrate that data with its own observations of 
ocean waves, temperature, etc. to form complete data set 
files for download and use by anyone. Access networks 
provide the technologies for moving many of the data 



Figure 3, Backbone Network Model for GN, DSN, and SN 



Figure 5, Access Network Model - for Spacecraft to Backbone 


reduction tasks to the on-board processor. 

As future on-board networks become compliant with Inter- 
net protocols (IP's) they will also come to resemble 
ground-based LAN's [3] [4]. In the case of a science space- 
craft, the on-board LAN (see Figure 5) is part of an access 
network that provides the interfaces for the science instru- 
ment to access information and services from the on-board 
resources. The information might include time and events 
data from the spacecraft subsystems, coordinated science 
data from other instruments, and overlay data provided 
from the ground or other spacecraft. Services provided by 
the spacecraft could then include science data file storage, 
communications, protocol translation, data routing, auton- 
omous mission operations control, high level data product 
generation, and etc. Further, the instrument, via the on- 
board server and communication hardware, will access a 
backbone network node which connects the spacecraft to 
NASA's Intranet, the Internet, and ultimately the user. 
When the spacecraft is connected to the backbone, and the 
user is also online, real time communication with on- 
board LAN-connected instruments, and subsystems is pos- 
sible. Communications that happen during times when the 
spacecraft is not connected to the backbone are handled by 
the on-board server. The server provides temporary storage 
for science data and autonomously passes that data to file 
backbone during connection periods. 

Inter-spacecraft Networks 

Spacecraft that fly in cooperation, such as in constella- 
tions, tight formations, or loose clusters, incorporate an 
inter-spacecraft network for local communications and 
coordination. Such geometries may use a wireless inter- 
face (radio or optical) or a tether interface (wire or fiber 
optic) to interconnect neighboring spacecraft. In many 
concepts the inter-spacecraft network also takes part in the 
measurement of relative position between spacecraft. 

A few geometries for formation and cluster flying are 
shown in Figure 6. It is possible to assign several back- 
bone ground stations to communicate with each spacecraft 
in a formation or cluster simultaneously. This type of 
operation is difficult to coordinate, however, and stretches 


the capability of the backbone. For that reason, a good 
solution is to assign a single member of the formation to 
handle the access network interface responsibilities 
between the formation and the backbone network. Tight 
flying star formations that use a single spacecraft to coor- 
dinate the operation and control of the formation's mem- 



Figure 6, Inter-spacecraft Network Elements 



Figure 7, Inter-Spacecraft Network Model - 
for Spacecraft to Spacecraft 




bers might also use that spacecraft to handle the communi- 
cations tasks. 

Other solutions might pass the communications interface 
off to any one member at a time, if that member is part of 
an ad hoc formation or cluster. In the ad hoc case, the 
member that connects to the backbone could act as a “bent 
pipe” connection for the other members to send their data 
to the backbone. The figure shows only a few possible 
coordinated structures. NASA will continue investigating 
these and other structures to find optimum ways of operat- 
ing each, identifying the technologies needed to make 
them work, and synthesizing requirements for those tech- 
nologies. 


As shown in Figure 8, entities in a local area form a flexi- 
ble network to pass data between them and to pass data to 
entities designated as coordinating nodes. Over-flying 
orbiters can act as short term members of the landed ad 
hoc group by passing data between entities that cannot 
“see” each other well enough to communicate. The over- 
flyers would also relay the group’s finished data to earth 
and pass mission tasks from earth to the group. 

The proximity network protocol structure shown in Figure 
9 is very similar to the inter-spacecraft structure shown in 
Figure 7. The data rates will likely be somewhat lower due 
to the use of low power consumption communication and 
computing components. 


If the inter-spacecraft links are implemented as attach- 
ments to each spacecraft’s LAN, as shown in Figure 7, 
then direct communications between instruments and sub- 
systems on different spacecraft are facilitated. This scheme 
seems quite flexible and might be used to pass data 
between spacecraft so as to distribute the overall data pro- 
cessing load. 

Proximity Networks 


Closely spaced, landed and airborne entities (vehicles, 
stations, sensors, balloons, etc.) will intercommunicate 
using low power proximity networks in an ad hoc fashion. 



Figure 8, Proximity Network Elements 


At higher data rates this ad hoc proximity network concept 
also provides a model for handling communications in the 
vicinity of the International Space Station (ISS). As activi- 
ties around ISS increase with Shuttle and Soyuz 
arrivals/departures and human/robotic maintenance and 
build activities, the local communications system must be 
able to autonomously reconfigure to accept new arrivals 
and drop-off those that leave. This proximity network can 
then be used to provide communications between all mov- 
ing entities as well as provide a means of warning of 
impending collisions. The same network would provide 
video connectivity for an ISS coordinator to monitor/guide 
robot or human activity. 

3. Architectures For The Earth Science 
Enterprise (ESE) 

The technologies for the Earth Science Enterprise (ESE) 
missions enable very high rate data transfers between the 
ground and low earth orbit (LEO), the Moon, and the 
vicinity of Earth’s orbit around the sun. The new technolo- 
gy initiatives [1] in high bandwidth microwave and optical 
links and in the space Internet enable Direct Data Distribu- 
tion (D3) to the scientist and public, High Rate Imagery 
Processing and Delivery (HRIPD), and the gathering of 
specialized products for environmental monitoring and 
forecasting. Lightning/rain correlations, storm, fire, and 
plume/gas tracking, crop and ocean health and pollution 
monitoring, and etc. are all improved with near real time 



Figure 9, Proximity Network Model - for Sensor Net (Landers/Stations, Rovers, Aero- 
bots, Airplanes, etc.) and to Relay Spacecraft 



finished data product availability to any interested person 
on the Internet. 

Figure 10 shows the general architecture of the ESE com- 
munications networks. Missions use the access and space 
and/or ground backbone networks to pass high rate data, 
low rate telemetry, and commands between the spacecraft 
and ground. Missions supported by ESE networks include 
the Earth Observing System (EOS), Triana, Geospace 
Electrodynamics Connections (GEC), NOAA weather sat- 
ellites, Landsats, atmospheric chemistry and physics 
experiments, earth plasma and solar wind interaction 
experiments, and others. 

The figure indicates a future in which a mission might use, 
at its convenience, the SN, or a commercial communica- 
tions satellite system, or the GN. NASA is developing the 
standard interface technologies for the access and back- 
bone networks that are needed to enable a spacecraft to 
connect through any network system. Whether or not a 
mission needs the flexibility to connect to any backbone is 
then left up to the mission development team. The plan is 
to have the capability in-place. 

The technologies for inter-spacecraft networks will apply 
to any cooperative multi-spacecraft missions that are 
implemented. Missions of this type being considered 
include: Magnetospheric Constellation (MC), Magneto- 
spheric Multiscale (MMS), and the Nanosat Constellation 
Trailblazer (ST5). 


ESE will also benefit from work on low power proximity 
networks. Ground, sea, air, and space sensors that measure 
Earth’s parameters will communicate with each other and 
with data gathering spacecraft using these technologies. 

4. Architectures For Human Exploration 
And Development In Space (HEDS) 

Architectures for the HEDS enterprise (Figure 11) will 
likewise benefit from the very high data rate transfer capa- 
bilities of the future networks. These technologies provide 
clear examples of the benefits of developing for the gener- 
al benefit of the NASA enterprises rather than for specific 
mission requirements - all missions get a better overall 
system. General technologies that benefit HEDS include 
Ka/Q/V-band and optical technologies, utilization of com- 
mercial satellites, and improved utilization of government 
communication satellites. Other features of general utility 
are D3 to the scientist and public, and IP-based communi- 
cations for shuttle/ISS which will handle voice, video, 
data, and emerging commercial and military broadband 
services. 

NASA is also investigating a Very High Rate Data 
(VHRD) augmentation to the backbone networks that will 
ensure near continuous connection of ISS to the Internet at 
several Gbps. This augmentation comprises a spacecraft 
that flies in the orbit of but trails ISS at a safe 1000 km or 
so. The spacecraft communicates with ISS with a modulat- 
ed optical beam. It then serves as a router by sending (in 



Figure 10, ESE Architectures 





Figure 11, HEDS Architectures 


the Ka-band) data up to an available TDRS or commercial 
communications satellite or down to a ground station. 

Self forming and dissolving ad hoc proximity networks 
may be necessary to the coordination and safety of work in 
the external ISS vicinity. These ad hoc networks are an 
important part of several mission concepts under study in 
the other enterprises. It‘s likely that common solutions can 
be found that would be inherently superior to re-inventing 
these networks for individual missions. Solutions already 
emerging from the commercial sector are the IEEE 802.11 
and the European originated Bluetooth specifications as 
well as the open and the proprietary specifications for the 
cell phone environment. IEEE 802.11 and Bluetooth are 
tailored for communication between multiple computers in 
a slow mobile environment. Bluetooth generally operates 
below 1 Mbps but IEEE 802.11 can operate at respectable 
speeds ranging from 2 to 11 Mbps with future implementa- 
tions going above 50 Mbps. At these speeds, members in 
an ad hoc group around the vicinity of the ISS can easily 
pass voice and video between them to enhance safety and 
improve in-space work effectiveness. These specifications 
handle communications in an ad hoc group by autono- 
mously picking up new members and dropping off those 
that pass out of the range of the group. 


5. Architectures For The Space Science 
Enterprise (SSE) 

Technologies for the SSE are derivations from the technol- 
ogies being developed for the other enterprises [1][4]. 
Deep space missions and missions to Mars will also take 
advantage of the high bandwidth microwave and optical 
links being developed for general use. The Mars Network 
will eventually employ surface-to-orbiter access links and 
surface-to-surface proximity networks, as well as the K- 
band and optical link technologies that are also being 
developed for ESE and HEDS. 

The Earth-side networks for SSE are shown in Figure 12. 
These include the GN that is used to communicate with the 
in-space observatories for the Origins and Sun - Earth 
Connection programs and the Deep Space Network (DSN) 
that is used to communicate with spacecraft normally 
beyond 2 AU. The in-space observatories are placed in the 
vicinity of Earth - from LEO out to the libration points at 
LI, L2, L4 and L5. The access networks for these observa- 
tories will utilize Ka-band communications and become IP 
compliant such that data from the observatories will be 
available to scientists and the public in near real time. The 
networks will enable each using scientist, in turn, to have 
full control of an observatory via the Internet. 




Ground stations located at Goldstone, California, Canber- 
ra, Australia, and Madrid, Spain comprise the Earth-side of 
the DSN. The larger antennas, 34m and 70m, form part of 
the backbone network to Mars and the access network for 
other deep space mission spacecraft. The DSN is being 
and will continue to be upgraded to Ka-band operation. 
Optical communications from telescopes atop mountains 
may also be added as a DSN capability. 

Communications delay times to deep space missions 
become too long for real time human interaction with a 
mission during critical and emergency operations. Because 
of this, mission spacecraft must perform critical and emer- 
gency procedures autonomously. A beacon mode system 
will be implemented at the DSN sites to assist these auton- 
omous operations and to reduce the overall cost of opera- 
tions. The beacon system is implemented with smaller 
diameter antennas that operate at very low bit rates. Some 
antennas are operated as lighthouse beacons that send tim- 
ing and ranging return signals to spacecraft. A spacecraft 
receiving this beacon signal can synchronize its clock with 


earth-time and can determine its distance from earth by 
timing the return of a signal it has sent to a receiving bea- 
con and that was sent back by the lighthouse beacon. The 
spacecraft can also use one-way Doppler to determine its 
velocity relative to earth. 

A spacecraft will also send a beacon signal back to earth to 
indicate the state of its health and to request communica- 
tions service from the DSN. This part of the beacon system 
will save costs by utilizing smaller antenna assets for the 
task of monitoring many spacecraft during the quieter 
phases of their missions and by autonomously calling in 
the larger assets only when needed for emergency or for 
support of mission critical data reception. 

A backbone network between Earth and Mars is shown in 
Figure 13. The present thoughts for this network are that 
three communications spacecraft will be put in high alti- 
tude, high inclination orbits (but not in Polar orbit) about 
Mars. These spacecraft will usually be able to see each 
other and will cover fixed places on the surface for 




Figure 13, A Mars Communication Architecture 


reasonably long periods of time. Most places on the sur- 
face will be in view of an orbiter most of the time. This 
simple constellation can support many surface and balloon 
activities at a time. These spacecraft will incorporate store- 
and-forward servers to temporarily hold data for transfer to 
another surface element or to the Earth. The spacecraft 
may also include inter-spacecraft communications links to 
pass data around Mars from one surface site to another or 
to the Earth. 

In the more distant future, the solar system communication 


network shown in Figure 14 could be implemented. To 
implement this system, it is assumed that most of the large 
flexible structure technologies are in place so that large but 
lightweight communications systems can be placed in 
space at reasonable cost. In this concept, large antenna 
structures are tethered together with a control spacecraft 
and a large solar array. The solar array powers all the units 
through wires in the tethers. The control unit acts as a rout- 
er for sending data received from earth through the appro- 
priate antenna to a mission's spacecraft and for handling 
the mission’s data return route. All units handle their own 



Figure 14, An Architecture for High Data Rate Communications to Deep Space 



pointing and the central control unit ensures that the units 
don't collide. 

These tethered relay stations can be placed at various 
Lagrangian libration points such as the Earth and Jupiter 
L3, L4 and L5 points. Such relay stations could vastly 
improve the communications data rates to distant locations 
in the solar system 

6. Conclusions 

This paper has described a set of four architectural ele- 
ments that can be assembled into end-to-end communica- 
tions architectures to satisfy the real and perceived require- 
ments for future missions of NASA’s enterprises: ESE, 
HEDS, and SSE. The suggested elements are the backbone, 
access, inter-spacecraft and proximity networks. By deriv- 
ing each element’s functionality from the Earth-bound 
Internet’s technologies and protocols, cost savings can 
accrue from common use of technologies; and the advan- 
tages of D3 can be realized without the need for human 
assistance along the route. 

It is intended that these elements might serve as a basis for 
discussion of future architectures and for synthesizing the 
requirements of those architectures. Rather than develop 
entire new infrastructure to support a single mission, it is 
desirable to define and implement new architectural ele- 
ments that can be evolved over time by adding new capa- 
bility to service the new mission as well as any other new 
mission that may need similar services. The elements can 
then be utilized in a uniform way across the enterprises 
with variations only in those areas that are specific to a sin- 
gle enterprise ( e.g.; the very high data rates to handle mul- 
tiple streams of ISS video, voice, and scientific activity; 
and the communication technologies needed to accommo- 
date the very long delay times and weak signals associated 
with deep space missions). 

Some architectural constructs have been posed for future 
consideration. Two of these are the high-speed proximity 
network in the vicinity of the ISS and the solar system 
communications network that is enabled with inflatable 
structures and tethered clusters. 

The implementation of advanced architectures will require 
high capacity, high rate, reliable microwave or optical com- 
munication technologies for the backbone for near Earth 
and deep space. Primary enablers for these advanced archi- 
tectures include miniaturization of reliable network tech- 
nologies and mobile protocols that are delay insensitive 
and operate with minimum data overhead. All in-space 
architectural elements will, in general, require highly min- 
iaturized, low power, mass and volume network and wire- 
less hardware. 
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